1. Technical Field
This invention relates in general to data network performance measurements and, more particularly, to measuring delay/delay variation/loss (D/DV/L) in an IP multicast network.
2. Description of the Related Art
Multicasting data is used in a variety or circumstances. One of the most important upcoming uses for multicasting is the transmission of multiple channels of live video, sometimes referred to as IPTV. When live video is being sent over a data network using an IP protocol, rather than other transmission media, such as satellite and over-the-air, several quality of service issues arise: (1) L3 (Layer 3) routes (MRIB, Multicast Routing Information Base) may be improperly configured in PIM (Protocol Independent Multicast) routers, (2) L2 (Layer 2) FDB (Forwarding Data Bases) may be incorrect in bridges, (3) there may be a node or link failure and (4) packets may be delayed, or the time between packets may vary (delay variation), or packets can be lost (i.e., sent from the source, but not received at one or more of the receiving devices in a multicast group). Accordingly, there must be a way of testing performance of a data network when a suitable transmission is not being obtained by a specific subscriber.
The ability to quickly and accurately trace problems is of special importance for customer care and troubleshooting in the case of IPTV service offered using multicast: if a subscriber complains about poor QoE (Quality of Experience) when watching a certain channel, the network operator must investigate different areas (network configuration, current congestions or failures, and so on). An additional useful tool would be to test the current D/DV/L performance of a given channel, from its source to that particular receiver. D/DV/L measurements are also important for other multicast services, such as videoconferencing (for which D/DV are important) and file distribution (for which L is important).
Currently, end-to-end solutions at the IP level (layer 3) to measure D/DV/L are categorized as either passive or active. In the passive method, real traffic is observed with external hardware and the observed information is correlated. In an active measurement, unicast measurement traffic (such as IP Performance metrics, or IPPM, specified by the IETF, Internet Engineering Task Force, working group) using timestamps, type and sequence identification fields, plus additional padding, with randomized sending times a padding bits, is injected into the network. The performance measurement packet fields are used to compute D/DV/L performance characteristics, sort them locally and make them available for NM (network management) retrieval. The protocol OWAMP (One-Way Active Measurement Protocol) allows two hosts to negotiate measurement sessions of TCP, and the measurement packets are sent over UDP (User Datagram Protocol).
IPPM is also currently specifying multi-party (one-to-many) metrics, which covers the case of multicast, at the group level (D/DV/L are measured for every receiver in a group, and the information is gathered for the group). One other category of measurement is the use of node implemented counters, but these counters only measure losses, not delays or delay variations.
External hardware for passive measurement solutions is expensive for network monitoring, and especially so for a case-by-case troubleshooting tool. On the other hand, unicast injected traffic in an active measurement solution fails to capture the specific performance of multicast data paths, since unicast packets are likely to be enqueued and processed differently in the network nodes, thus experiencing a QoS (quality of service) which is different from the multicast traffic.
Unicast packets can also be forwarded differently (i.e. follow a different path) in both multicast models—the SSM model (Source-Specific Multicast, with a SPT: Shortest Path Tree) and the ASM model (Any Source Multicast, with a RPT: Rendez-vous Point Tree, possibly extended during operation with dynamically built SPTs), implemented using PIM-SM (Protocol Independent Multicast, Sparse Mode). The topology of a multicast tree depends on the upstream IP path from the listeners to the source (RPF: Reverse Path Forwarding), whereas the D/DV/L performance should be measured downstream from the source to the receivers. In ASM, multicast packets may follow the RPT before an SPT is established, thus resulting in a route possibly very different than the SPT.
The future IPPM multiparty metrics (covering multicast) will allow measurement of average D/DV/L performance within a multicast group, but this will generate excessive traffic if used just for one receiver, since all receivers will be flooded with the performance measurement packets.
Therefore, a need has arisen for a D/DV/L measurement that does not require expensive additional equipment, and which accurately measures D/DV/L for a single receiver without excessive PM traffic.